Coverage increased (+2.5%) to 97.815% when pulling 381267a on joaovieira:extend-ts-export-assignment into 9516152 on benmosher:master.

Coverage decreased (-0.4%) to 96.151% when pulling 86d2eff on joaovieira:extend-ts-export-assignment into 112a0bf on benmosher:master.

It should read about esModuleInterop option or add an equal option for this plugin instead of hard coding the logic IMO.

@JounQin can you elaborate?

TS's module system is broken without synthetic imports and esModuleInterop enabled; I'm completely comfortable telling people they need to enable those if they want stuff to work properly.

What a great PR! I was searching for a solution all day, finally gave up and started to dig into the sources. Strangely enough, this PR didn't come up while I was searching for similar issues.
So, I started coding basically the same thing: #1689

@JounQin I agree with you, in my PR I'm reading from tsconfig.json. But, there might be multiple tsconfigs and they might include/exclude specific files. So, the best approach would be to first, figure out which tsconfig is covering file where the import is made and then check if that config has esModuleInterop enabled.
Here's an example of code from eslint-import-resolver-typescript that does kind of similar thing:

mappers = configPaths!
  // turn glob patterns into paths
  .reduce<string[]>(
    (paths, path) => paths.concat(isGlob(path) ? globSync(path) : path),
    [],
  )
  .map(loadConfig)
  .filter(isConfigLoaderSuccessResult)
  .map(configLoaderResult => {
    const matchPath = createMatchPath(
      configLoaderResult.absoluteBaseUrl,
      configLoaderResult.paths,
    )

    return (source: string, file: string) => {
      // exclude files that are not part of the config base url
      if (!file.includes(configLoaderResult.absoluteBaseUrl)) {
        return undefined
      }

      // look for files based on setup tsconfig "paths"
      return matchPath(source, undefined, undefined, extensions)
    }
  })

That being said, we should either do the right thing and figure out how to handle complex cases. Or, we can do the simple thing and only cover simple case (only root tsconfig) or introduce new leg in parserOptions that will also act globally but will be more explicit than assuming that everybody has only one tsconfig.

Also, I can't disagree with @ljharb about assuming that everyone uses esModuleInterop nowadays. It seems to be a pretty popular flag to use. And in this case, I would be very happy to see this PR merged, thanks!

Nice fixing 🚀! When is it going to be released?